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A Real-time Group Auction System for Efficient 
Allocation of Cloud Internet Applications 

Chonho Lee, Ping Wang, Dusit Niyato 

Abstract 

Increasing number of the cloud-based Internet applications demands for efficient resource and cost 
management. This paper proposes a real-time group auction system for the cloud instance market. The 
system is designed based on a combinatorial double auction, and its applicability and effectiveness are 
evaluated in terms of resource efficiency and monetary benefits to auction participants (e.g., cloud users 
£Nj \ and providers). The proposed auction system assists them to decide when and how providers allocate their 

;_i ■ resources to which users. Furthermore, we propose a distributed algorithm using a group formation game 

that determines which users and providers will trade resources by their cooperative decisions. To find how 
to allocate the resources, the utility optimization problem is formulated as a binary integer programming 
problem, and the nearly optimal solution is obtained by a heuristic algorithm with quadratic time complexity. 
In comparison studies, the proposed real-time group auction system with cooperation outperforms an 
individual auction in terms of the resource efficiency (e.g., the request acceptance rate for users and 
resource utilization for providers) and monetary benefits (e.g., average payments for users and total profits 
for providers). 
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1 Introduction 

K/ Cloud computing is a large-scale distributed computing leveraging Internet-accessible data cen- 
ters that provide computing resources (e.g., CPU, memory, storage, and network bandwidth) 
as cloud. Modern Internet applications are designed using the virtualization technology in the 
cloud computing environment. Such cloud-based Internet applications are deployed on virtual 
machines (VMs), also called instances [I] whose resource requirements are pre-configured. Cloud 
users (e.g., application developers) request a certain number of instances to run their applications, 
which are hosted by cloud providers (e.g., owners of physical machines). According to the 
number of instances that cloud users use, cloud providers charge the fee for what the cloud 
users used. 

This paper studies the issues of cost efficiency for cloud users and resource efficiency for cloud 
providers. Users are required to minimize the cost to deploy and run their applications on clouds 
and to maximize the reliability of the applications by improving the resource availability. On the 
other hand, providers are required to maximize their revenue by attracting users and improving 
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the resource utilization. However, it is hard for users to determine which providers that they 
should trade with, and vice versa, to meet their objectives under dynamic and unpredictable 
resource demands, supplies, prices, and budgets. 

The goal of this paper is to design a real-time auction system for the cloud instance market 
where multiple cloud users and providers respectively buy and sell instances to run and host 
cloud-based Internet applications. The proposed auction system assists the auction participants 
(i.e., both cloud users and providers) to decide how providers allocate their resources to which 
users in order to improve both cost and resource efficiency. 

To achieve the goal, we introduce a group auction and the participants' cooperation. A group 
auction is a type of auctions and a market method that benefits both buyers and sellers. Specif- 
ically, sellers offer buyers price discounts according to the number of requested items (i.e., the 
more the requested items, the lower the price). One example scenario of such auction is the online 
group-buying shopping sites 0, [U, and flU, which have recently become popular. However, 
the group auction has not been extensively analyzed in cloud computing although it has been 
well studied in economics. One of the objectives of this paper is to investigate the applicability 
and effectiveness of a group auction to the cloud instance market. 

In the proposed group auction, multiple cloud users are allowed to form a group, called a 
user coalition in order to buy their instances at a discounted price. Multiple cloud providers are 
also allowed to form a group, called a provider coalition and share their resources to effectively 
use the residual resources, which results in the improvement of resource utilization. 

In such a cooperative system, users expect to buy instances at a low price, and the providers 
expect to attract more users to improve the resource utilization and thus to increase their 
revenues. However, the cooperation may cause a delay of the instance allocation (e.g., by waiting 
for more users to join an auction) and a cost for the instance migration (e.g., a cost incurred 
by the performance degradation of applications when instances are migrated to different servers 
in different providers). There is a need for the analysis of participants' cooperation decisions, i.e., 
when to or not to cooperate. It is challenging to find stable set of such decisions, which satisfies 
all of rational participants trying to maximize only their own benefits. The contributions of this 
paper can be summarized as follows: 

• We propose a real-time group auction system in the cloud instance market, which is designed 
based on a combinatorial double auction, and verify its applicability and effectiveness in 
terms of resource efficiency and benefits to auction participants. 

• We propose a distributed algorithm using a group formation game that determines which 
users and providers will trade resources by their cooperative decisions. 

• The utility optimization problem is formulated as a binary integer programming problem for 
the resource allocation, and the nearly optimal solution is obtained by a heuristic algorithm 
with quadratic time complexity. 

The proposed real-time group auction system gives auction participants the resource efficiency 
(e.g., 13% higher request acceptance rate for users and 26% higher resource utilization for 
providers) and monetary benefits (e.g., 7% lower average payments for users and 6% higher 
total profits for providers) compared to a conventional individual auction with the best-fit 



IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. XX, NO. XX 3 

allocation. The proposed group formation and instance allocation algorithms are analyzed in 
their complexity, stability, and optimality The results show that the algorithms with quadratic 
time complexity always obtain a nearly optimal group structure regardless of configurations and 
initial conditions. The proposed system acts as a glue that binds cloud users and providers, and 
it can be used by providers or third parties (i.e., brokers) for efficient cloud service delivery and 
resource management in the practical system. 

The remainder of this paper is organized as follows: 

• Section [2] introduces existing related work and summarizes their similarities and differences 
from our work. 

• Section [3] explains how the cloud instance market works in a group auction manner, and 
then overviews a system model for the proposed group auction. Some assumptions that we 
considered in the system are stated in this section. 

• Section H] formulates the instance allocation as the social welfare optimization and presents 
in detail how to achieve the nearly optimal solution by the proposed group formation 
algorithm. 

• Section [5] gives a theoretical analysis of the proposed group formation algorithm in terms 
of the time complexity and stability. 

• Section [6] discusses the convergence and optimality of the proposed algorithm on numerical 
results and compare the results with different schemes through the simulation, which is 
followed by a conclusion. 

2 Related Work 

This section introduces existing related work and describes their similarities and differences from 
our work, which are summarized in Table [T] in terms of resource allocation methods, auction 
types, and cooperation methods. 

Resource Allocation 

The importance of resource provisioning has been well discussed in various fields such as 
wireless networks, energy industries, and advertisements, which have proposed the allocation 
and pricing model of resources (e.g., wireless channels @, 0, electricity 00, DHL and adver- 
tisements IflQl , EH) to improve the resource utilization and efficiency. We focus on instances in 
clouds and consider an instance market where computing resources (e.g., bandwidth, CPU time 
and memory space) are traded as instances. 

For the resource allocation, there exist several techniques such as game theory finding an equi- 
librium solution among players fl2|, ITT31 ; stochastic programming considering uncertainty fHf; 



and bio-inspired mechanisms (e.g., genetic algorithm that seeks a Pareto solution of a multi- 
objective problem [15] and Ant colony that provides a heuristic solution of a complex prob- 
lem [16)]). We apply the auction theory to design the cloud instance market and formulate its 
instance allocation. 

Auction-based Mechanism 
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TABLE 1: Summary of related work (A symbol "-" indicates omission for out of the paper scope.) 



Resources 


Allocation methods 


Auction-based 


Others 


Electricity 


[8,9] 


- 


Wireless spectrum 


[6, 17, 18] 


- 


Cloud instances 


Our work 
[19, 20, 24, 25] 


[12, 14, 15 
16, 21, 22] 


Others 


[2, 3, 4] 


- 



Auction types 


Single-sided 


Double-sided 


Individual 


[24] 


[19, 20, 25] 


Group 


[2, 3, 4] 


Our work 



Cooperation 


Centralized 
decision 


Self-interested 
decision 


Buyers 


[22] 


[21] 


Buyers and /or Sellers 


- 


Our work 



Auction-based mechanisms have been proposed in various fields such as wireless networks 
and cloud computing in order to investigate how participants (or nodes) behave in a competition 
for resources; and different classes of auctions such as sequential second price auction |fT7|, 
Vickrey auction IfTBl , double auction [19], and combinatorial auction [20] have been considered 
in the design of the mechanisms. However, none of them considers a group auction and the par- 
ticipants' cooperation. We investigate a combinatorial double auction executed in a group-buying 
manner and analyze the optimal allocation by observing participants' cooperative decisions in 
a group (or coalition) formation game. 

Cooperation 

Cooperation is one of the important concepts to improve the resource efficiency. The dis- 
tributed resource management schemes in computational grid were developed with negotiation 
algorithm [[2T]| and coalition formation algorithm [22]. These schemes allow rational agents 
managing server farms to form the cooperation to share available resources. The cooperative task 
scheduling has been proposed in [23]. It was shown that it is always possible to obtain collabo- 
rative solution of the self-interested agents which can improve the global system performance. 
We adopt the concept of cooperation among users and providers under the consideration of both 
the cost and resource efficiency. None of the works considered a dynamic instance allocation in 
a group auction from the coalitional game perspective. 

Cloud Instance Market 

The proposed work differs from the major cloud hosting services such as AmazonEC2's Spot 
Instance [24] and SpotCloud [25], which deal with the instance market. j|24l tries to sell the 
residual resources to cloud users to achieve high resource utilization. Users join an auction to 
reserve instances and pay for the resources at a dynamically changing spot price offered based 
on the supply-demand conditions. Our work is similar to this in terms of the trading price 
changed based on supply-demand conditions. But, [24] is considered to be a one-sided auction 
that users' requests are individually processed in a first-come-first manner. Our work is a double 
auction executed in a group auction manner. 

Similar to the proposed system, 11251 works as a double auction, and resource prices change 
depending on providers' valuations to the resources. Users submit their instance requirements, 
and providers submit profiles of hardware to be supplied. [25j lists the profiles best-matched for 
the user requirements, and the users will choose what they want from the list. For providers, 
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1125 II automatically creates instances on providers' machines requested by users. Our proposed 
approach can be applied to such SpotCould market to automate the users' provider selection 
step; it tries to find the best matching of users and providers cooperating each other to gain 
benefits in terms of monetary cost and resource efficiency. 

In the evaluation section, we verify the impact of group auction and cooperation by comparing 
the proposed scheme with the two schemes. However, for the fair comparison, we extend them 
as follows, and we respectively call IA-FCFS and GA-BCT (described in Table 4). IA-FCFS mimics 
|24| but considering multiple providers, and we try to observe the impact of group auction. GA- 
BCT mimics [25] but following our allocation algorithm, and we try to observe the impact of 
cooperation among users and providers. 



3 The System Model and Assumptions 

3.1 Cloud Instance Market 

We consider the system model for the cloud instance market where multiple cloud users and 
providers respectively buy and sell instances in a group auction manner. To buy/sell instances, 
the users /providers submit bids /offers to a central controller which supports the instance allo- 
cation and pricing determination. This paper considers a discrete-time (e.g., 15 minutes or half 
an hour) system so a concept of time slot is involved. We say time slot t for a period between 
time t — 1 and time t. For example, saying that the system collects 3 bids at time slot 5 means 
that 3 bids are submitted during a period between time instants 4 and 5. 

The system deals with K different types of instances. The instance in different types will 
require the different size of computing resources such as memory, storage, CPU capacity (e.g., 
EC2 Compute Unit]), and network bandwidth associated with I/O performance (e.g., throughput 
and latency). For example, Amazon EC2 [1J offers various types of Standard Instance shown in 
Table |2j Different providers provide various types of instances with different combinations of 
computing resources. 

TABLE 2: Types of Standard Instance Family in Amazon EC2 



Instance type 


Small 


Medium 


Large 


Ex-large 


Memory 


1.7 GB 


3.75 GB 


7.5 GB 


15 GB 


Storage 


160 GB 


410 GB 


850 GB 


1690 GB 


EC2 Compute Unit 


1 


2 


4 


8 


I/O performance 


Moderate 


Moderate 


High 


High 



Modern Internet applications are designed using multiple servers at multiple tiers, each of 
which provides a certain functionality 1126 II . For example, a front-end Web server is responsible 
for HTTP processing, a middle-tier Java application server implements the application logic, 
and a back-end database server stores user information. The different tiers of an application are 
assumed to be distributed across different servers. Depending on the desired capacity, a tier may 
also be clustered by multiple servers of the same type, which are connected in parallel. 

1. One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor. 
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The servers are requested /provided by users /providers as instances II27L [28] mentioned above. 
A cloud user requests a bundle of instances that represents a multitier application and buys the 
instances in a taking-all-or-none manner. For example, a user requests four Small instances (for 
Web servers), two Large instances (for application servers), and one Ex-large instance (for a 
database). If one of the requested instances cannot be provided, then other requested instances 
become useless to the user. We also assume that the bundle of instances will be hosted by one 
provider to take advantage (e.g., high throughput and short latency) of the proximity among 
servers for an application. 

3.2 Participants of the Cloud Instance Market 

3.2. 1 Cloud Users 

A cloud user i submits a bid defined by hi = (di, £i, u«) where di = (dj, df, . . . , df) T is a demand, 
and d\ indicates the number of instances of type k. £i = (£i,tf,t?) T is a demand period where 
£i indicates a length of time that the user i wants to reserve a bundle of the instances between 
starting time tf and ending time t\. For example, ^ = (3, 2, 8) indicates that user i requests instances 
for 3 time slots (that do not have to be consecutive) between time 2 and time 8, each of the time 
slots reserves di instances. We define tf = t\ — £i and call it the deadline by which the instances 
should be assigned to satisfy the demand. v,- t is user i's valuation for the demand as a bidding 
price, which indicates the maximum price that is acceptable for the user to buy the requesting 
instances. 



3.2.2 Cloud Providers 

J 3 ' J J ' • • • ' J J 



A cloud provider j submits an offer defined by Oj = (sj,wj,Qj) where Sj = (s),s|, . . . , sf v 



is a supply and s, indicates the number of instances of type k that provider j can provide 



per time slot. Wj = {t%tfj is a supply periods. Wj = ft — tj denotes a length of time that a 
provider is able to provide the instances between t? and ft. Qj is provider j's valuations for the 
supply as an offering price curve, which indicates the minimum of a unit price of the offered 
instances that the provider wishes to sell. It is defined by a set of vectors over different number 
of instances and instance types as follows: Qj = (g*, g|, . . . , qf) where g* = (g|[l], • • • , cfiV^]) 7 , 
and g*[n] indicates the offering price when n instances of type k are sold by provider j, and 
Qj[Q] = +°°- $ holds a condition qj[l] > ••• > q k j[n^\. Let Qj[nj\ denote an extraction of the 
price curve when ry = (wj,n|, . . . ,nf) instances are sold, which is represented as a row vector 
QAnl] = (q][n]],q][n%...,qf[nf]). 

3.3 Overview of the Proposed Group Auction System 

The central controller maintains the bids and offers collected from cloud users and providers 
respectively, and computes when and how to allocate resources to which users. Figure [Q is a 

2. We formalize the supply period as variables whose values are different for different providers. The providers might be 
personal providers or small companies that supply their resources for limited time periods |25| while large providers ]1 [ do not 
limit the supply period in general. 

3. In practice, the provider's valuation to an instance is determined based on several factors such as the value of applications 
to users, the running cost of servers, and other competing providers. It is beyond our work in this paper to understand how 
providers set their own valuations. For simplicity, we assume that the valuations are pre-determined. 
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Fig. 1: A flowchart of the proposed group auction system. 



flowchart of the proposed group auction system and shows how the central controller works. 
The system undertakes three main tasks such as the allocation computation (Labels (T) and (2)), 
the result reporting (Labels (3) and (§)), and the payment management (Label ©). 

Whenever the central controller receives new bids /offers, it updates their information on 
database and computes the best instance allocation (Label CD) adopting a concept of cooperation 
among users and providers (described in the following section). If the controller closes the 
bid/offer submission (Label ©), it reports the recently computed instance allocation to providers 
(Label (3)) and announces to users who are the winners /losers of the auction (Label (§)). Once 
the charging and payment are complete (Label ©), users and providers establish the connection 
and start to run/host applications (Label ©). 

The instance allocation is formulated as a social welfare (or utility) optimization problem, 
and the solution is obtained by the proposed group formation algorithm. The trading prices 
are determined based on the social welfare distribution scheme. The details are presented in 
Section HI The formulations of both allocation and pricing are considered to satisfy three auction 
properties as follows: 

• An allocation is allocatively efficient if there are no participants who gain utility from decreasing 
others' utility. 

• An allocation is individually rational if participants are never charged more than their valua- 
tions as a result of the allocation. 

• An allocation is budget-balanced if the total profits of providers is the same as the total 
payments by users. 
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Fig. 2: An example allocation when (a) users cooperate and (b) providers cooperate. The shaded 
box indicates the allocated instances. The height of the box represents the number of instances. 



3.3. 1 Cooperations among Users and among Providers 

In the proposed system, users and providers can form coalitions to gain benefits in terms of 
resource price and resource utilization efficiency. Figure |2] shows two examples explaining two 
types of cooperation. One, illustrated in Figure 2(a), is the case that multiple users request 
resources of the same provider to lower the instance price. Another, illustrated in Figure 2(b), 
is the case that multiple providers supply resources to meet the same user's request. An edge- 
dotted line indicates the allocation of a user and a provider. A shaded box indicates the allocated 
instances. The height of the box represents the number of instances. 

For the first type, multiple cloud users are allowed to form a group, i.e., we call a user coalition, 
and request instances of the same provider in order to buy the instances at a discounted price. 
For example, when two users request 10 instances {d\ = 4 and d 2 = 6) as a coalition, a provider's 
offering price changes from q[A] (or q[Q}) to q[W] where q[A] = q[6] > q[10]. However, a cooperation 
may incur a delay of the instance allocation because different users have different demand 
periods. Figure |2fa) explains the delay (denoted by an arrow) of User 1 forming a coalition with 
User 2. Instances for User 1 could be allocated from time t\. 

For the second type, multiple cloud providers are also allowed to form a group, i.e., we 
call a provider coalition. The providers in the same coalition can share users' demands to meet 
their requests. For doing this, users' instances can be migrated from one provider to another 
as indicated by a down arrow in Figure Eflb). This cooperation enables the effective use of the 
residual resources and improves their resource utilization. However, the cooperation may incur 
a cost for the instance migration. For example, during migration, the degradation of application 
performance (e.g., throughput and response time) can be considered as the cost. 

3.3.2 Allocation and Bid Closing Time 

Denote B t as a set of bids and O t as a set of offers that the controller retains at time t, respectively. 
A demand period for demands in B t is specified by t — min{£f |£ 4 S e bi, Vfej e B t } and t = max{tf \tf e 
bi,\/bi e B t }. The allocation at time t is defined by a three-dimensional (\B t \ x \O t \ x (t — t)) matrix 
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Fig. 3: An example of allocation in a group consisting of 3 users and 1 provider over the demand 
period of 8 time slots. 
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\B t \, j = 1, . . . , \O t \, s = t + 1, . . . , t where a binary variable a ijs is 1 if user 



i's demand is allocated to provider j at time slot s, and otherwise. We assume that a user's 
demand is satisfied when all of the numbers of requested instances is allocated. Also, we assume 
that user's instances are allocated to one provider at each time slot. Thus, the system does not 
consider the partially allocated instances. We denote the optimal allocation by A* t = [a* js ], where 
the method to obtain it will be discussed in the next section. 

Given the allocation A t , the controller computes the best time to announce the allocation 
information (denoted by in Figure 1). We call it bid closing time, which is denoted as t b = mhiA t {tf} 
where tf is the earliest time that user i's demand is allocated according to A t . Figure |3] illustrates 
an example of allocation for three users and one provider over the demand period of eight time 
slots. In this example, the allocation is A t = [on s , a 2 i s , a 31s ] = [(0, 0, 0, 1, 1, 1, 0, 0) T , (0, 0, 0, 1, 1, 1, 1, 0) T , 



the demand period is t 



£3 and t 



t\, and the bid closing time is t b 



fa 

i 3 . 



4 The Proposed Group Auction System 

The instance allocation is formulated as a social welfare optimization problem. The social welfare 
is iteratively improved by the proposed group formation algorithm that allows participants to 
make group formation decisions to increase their own payoffs. This section first explains the group 
and the group structure defined in this paper (Section 14. 1} and presents in details instance 
allocation formulation (Section I4.2|) and the method to obtain the nearly optimal solution by the 
group formation algorithm (Section |4.3|) . 



4.1 Group Structure 

A group denoted by G consists of a set of users G u and a set of providers G p , i.e., G = G u U G p . 
Note that G u can be an empty set while G p is a non-empty set (i.e., including at least one 
provider). Instances supplied by the providers are allocated to the users in the same group. 
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Fig. 4: (a) An example of group structure formed by 5 users and 4 providers. For the readability, 
we respectively label 'u' and 'p' for users and providers, (b) Example group structures after 
migration (by u 3 ), merging (by p 2 ), or splitting decision (by p 2 ). 

Within a group, the users cooperate and get a discount when their instances of the same type 
are supplied by the same provider, and the providers are allowed to migrate instances among 
cooperating providers. 

A group structure denoted by f2 t is represented as a partition n t with a set of associated links L t 
between users and providers. The partition is a set of groups defined by 11^ = (G , G\, . . . , G m , . . . , Gm) 
where G m = {GJJ,, G^}, the m-th group of users G 1 ^ and providers G v m . G indicates a group 
of users without provider. The users in this group will not join an auction immediately due 
to resource limitation (i.e., they are likely to lose an auction) but wait for the next auction 
opportunity because the deadline has not been reached yet. Denote I t as a set of all users 
with the bids B t and J t as a set of all providers with the offers O t . The partition holds fol- 
lowing conditions u£f =0 G^ = I t and G u m n G u m , = for all m ^ m' , and \J™ =1 G p m = J t and 
G p m n G p m , = for all m ^ m! ' . Given the partition, a set of associated links between users 
and providers is defined by L t = u£f =1 {(i, j)|Vi E G^,3j e G p m } U {(i,0)|Vi G G }. Figure U[a) 
illustrates an example of the group structure formed by five users and four providers where 
Go = {4}, G x = {{1, 2, 3}, {1, 2, 4}}, G 2 = {{5}, {3}}, and L = {(1, 2), (2, 1), (3, 2), (4, 0), (5, 3)}. 



4.2 Instance Allocation 

4.2. 1 Formulation of Social Welfare Optimization 

Users and providers are allowed to trade their instances in their own groups. Given bids and 
offers in each group, the instance allocation of the group is formulated as an optimization 
problem to maximize the social welfare, i.e., the total utilities of the users and providers. 
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The utility of user i in group G with the allocation A t is given by 

Ui(G, A t ) =Vi- d 

n 

Vi / / "'ijs ' Pijs 

s=tf+ljeGP 

n 

= E E °y' s ■ ( Vis ~ %*) ^ 

s=tf+ijeGp 

— * 

where q is a final charge to user i, t> is = ^ is user i's valuation to instances di at time slot s, 
and Pij S is a trading price for the instances di between user i and provider j at time slot s. 
The utility of provider j in group G with the allocation A t is given by 



Uj(G,A t ) =r j -v j 

n 

= / J / J &ijs ■ Pijs — Vj 
jgG" s=tf+l 

n 

= EE a ^ • (p«- - E rf " • «? WJ) ( 2 ) 

ieG u s=tf+i fc 

where 7%, is a provider j's revenue and Vj is a provider j's valuation to the total amount of 
supplied instances D k - S = J2 ieG u a^g ■ d\ for k — 1, . . . , K. Therefore, the instance allocation A = 
[dijs] in group G is formulated as follows: 

max U(G, A t ) = V m(G, A t ) + V Uj(G, A t ) 

At ^—~* *—? 

i£G u jeGP 

n _^ n 

= J E E a ijs ■ (vis - Pijs) + E E E a ^ ■ ( pi i s ~J2 d i' ^ D U) 

ieG u s=t?+l j£GP jeGP ieG u s=tf + l k 
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ieG u i£G u s=tf+ljeGP k 
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subject to 

" (4) 

(5) 
(6) 

(7) 

for \/i G G u , Vj G G p , i < s < t, 1 < A; < K where t = min{£ 4 s |Vi G G u }, £ = max{t?|Vi G G u }. 

Thus, the social welfare optimization problem is formulated to find the instance allocation 
that maximizes the total utilities of users and providers (Equation (3)) under constraints (4)-(6) 
of the amount of supplied instances and about the allocation. Constraint (4) guarantees that 
the total number of requested /allocated instances does not exceed the total number of supplied 
instances. Constraint (5) indicates that a user's demand is satisfied when all of the requested 
instances are allocated, which is specified by a binary variable Sj. Constraint (6) indicates that 
user's instances are allocated to only one provider at each time slot, which is specified by a 
binary variable y is . Thus, the system does not consider the partially allocated instances. 

4.2.2 A Dynamic Algorithm to Find the Nearly Optimal Solution 

The formulated binary integer programming is known to be NP-hard that the number of differ- 
ent allocations to be evaluated exponentially increases as the numbers of users and providers 
increase. We propose a dynamic algorithm to find the nearly optimal solution in a reasonable 
time. 

Algorithm [T] shows the dynamic algorithm to find the nearly optimal solution given bids B t 
and O t at time t. The key idea of this algorithm is to give higher allocation priority to users who 
bid with higher valuation and providers who offer with lower valuation. Besides, the algorithm 
allocates instances from the time slot that more users request their instances to the time slots 
that less users request because providers are likely to offer a discount price in such time slot. 

At the beginning (Lines 1-9), the algorithm checks the users' demand periods and counts how 
many users request their instances over different time slots from t + 1 to t. C is a count vector, 
whose element C s indicates the number of users whose demand periods include the time slot s. 
Pos is a mapping between users and providers, whose element Posj is a provider id that a user 
i is assigned to. Posj = means that a user i is not mapped to any providers. 

In the following loop (Lines 12-37), the algorithm finds the allocation A t by starting to consider 
time slot s in descending order of the counts C (Line 12). The first subloop (Lines 16-30) computes 
the best mapping between users and providers at time slot s. According to the total number 
of instances requested by users in the same group (Line 21), the users with relatively higher 
valuations are preferably assigned (Line 30) to providers with relatively lower valuations if such 
providers j* exist (Line 23). If there is no such providers, then users consider other providers 
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in different groups (Line 26). If users cannot find any providers, then their demands cannot 
be assigned at this time slot (Line 25). The second subloop (Lines 32-36) updates the recent 
allocation based on the computed mapping. Once all instances requested by a user are mapped, 
the user % and his bid bi are excluded (Line 36). 

4.2.3 Trading Price Determination 

Based on the allocation, the trading price is determined in a way that the social welfare is dis- 
tributed to participants in proportional to their contributions, i.e., valuations. First, the controller 
computes the total price charged to users for each group G. The price at time slot s is given as 
follows: 

p Gs = k ■ 22 v ™ + ( X ~ K ) ' E v i s ( 8 ) 

ieG u jeGp 

= "-££ + (i-«)-££i>WW.] (9) 

iGG" * j£GP k 

where k E [0,1]. n is set to 0.5 in this paper to give users and providers the fairness. 

Second, the users in G divide the total price p Gs in weights proportional to the user's valuation. 
Hence, the price for user % is defined by 

p ijs = p Gs (10) 

l^i€G u V is 

= Y ' ( K ' £ Vis + ( X ~ K ) ' £ v i») ( 1V > 

s ieG" jeGp 

= a ijs ■ (« • v is + (1 - «) • — i • v js ) (12) 

' s 

where V s = Ylii&G™ v is ^ s the total valuation of users in G. 
Consequently, the cost (i.e., the total charge) for user i is 

n 

Ci = £ ^Pijs, (13) 



and the revenue for provider j is 



r ., 



E E p^- < 14 > 



4.3 A Group Formation Algorithm 

In the proposed system, the social welfare is further improved by the group formation al- 
gorithm that leverages the concept of cooperation among users and providers (as described 
in Section |3.3.1|) . The proposed group formation algorithm allows participants to make group 
formation decisions to increase their own payoffs. 
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Algorithm 1: findmstanceAllocation(.B t , O t ) 



Input: B t : a set of bids (from a set of users I t ) 

Ot- a set of offers (from a set of providers J t ) 
Output: A t = [ciijg]: an allocation 

2 /* Count the number of users whose demand periods are in timeslots s */ 

3 t <- min{i| | Vk e B t } 

4 t <- max{^ e | V6i G5(} 

5 for timeslot s ^— t + 1 to t do 



foreach user i e I t do 
[_ if if < s < t\ then C s <- C s + 1 



9 C «— (Q+i, Ct+2, ■ ■ ■ ,Cj) II A count vector 

io Pos <— (PoSi, . . . , PoS|/ t |) II A map-ping between users and providers 

n /* Find the allocation from timeslot in descending order of C s */ 
12 foreach timeslot s in sort(C,' 'descend') do 



13 

14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 

31 

32 
33 
34 

35 
36 



G g ^0 for g = l,...,|J t | 

I* Handling users in descending order of valuation |* */ 

foreach user i e I t such that tf < s < t\ do 
g 4-mm{g \ G g = $,g = 1, . . . , |J t |} 

for g «— 1 to g do 

/* /x = 1 if i $lU, and otherwise */ 

I* Find a provider with the lowest valuation */ 

j* <- argminj-gj^Uj = Efc^s ' ?*[-Dj] I v j < v u D s < s] s ,j £ V} 
if j* == then 

if g == g then POS; <- 

else P^PU {Pos m | 3m e GJ 



// A set of allocated users 



II A set of allocated providers 



else 



U ^UU{i} 

G g ^G g U {t} 

Pos m <- j* for Vm G G 6 



/* Update the allocation information */ 
foreach user i e I t do 
if PoSi ^ then 
|_ aj,Pos„ s «- l; ^ «- ^ - 1 
if £. == o then 
|_ J t «- I t - {i}; Bti-Bt- {b t } 



37 return A f 



njs] 
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4.3.1 Payoff 

The payoff for user i is designed as the difference between the utility and the delaying penalty 
by forming a group and defined as follows: 

W(G) = u>(G,A* t )-aG,A* t ) (15) 

where A\ = ar g max A t U(G,A t ), and the delaying penalty is defined by 

n 
Ug,a;)= J2 < js -zis-c d (16) 

s=tf+l 

where *.= ( S -*' ~ e < its >t ' + t > (17) 

1 otherwise. 

The actual cost C d may differ according to different participants, applications, and time slots. 
However, for simplicity, we assume that the actual cost is proportional to the delay. 

Similarly, the payoff for provider j is designed as the difference between the utility and the 
additional cost by migrating instances and defined as follows: 

cjf j (G)=u j (G,A* t )-^ j (G,Al) (18) 

where the cost for instance migration is defined by 

t 
^(G,A* t )= J2 m is-C m (19) 

a=t+l 

1 if a* js = 1 A a*., s _! = 1,3^ f 
otherwise. 



where m js = { ,, • ( 20 ) 



The migration cost C m also differs among providers. However, we assume the value to be a 
constant for all providers. 

4.3.2 The Proposed Group Formation Algorithm 

For constructing a group formation, we introduce an algorithm that allows users and providers 
to make the group formation decisions for selecting which groups (i.e., providers) to join and 
which users to accept. The decisions are called migrating, merging, and splitting. 

Migrating: Given a group structure Q — (U. — (G\, . . . ,G m , ■ ■ ■ ,Gm),L), any user i e G^ 
decides to migrate from its current associated provider j e G p m to another provider j' e G v m , 
where m ^ m! if the following condition is satisfied: 

C(GW U {i}) > ft(G n ). (21) 



The condition (|2Tj) guarantees for a user to improve its own payoff by performing the migrating 
decision. For every single migration of user i, the group structure f2 is updated to Cl' = (II', L') 
where II' = (n\{G m ,G m ,}) U {G m \{i},G m , U {z}}, and V = L\(i,j) U (i,f). 
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Merging: Multiple groups G m G IL,, a subset of II (i.e., II S C II) can collectively form a single 
group G^ m , if the following conditions are satisfied: 

3j e GP m , <%{Gfl,) > </>J(G m ), G m e U s (22) 

<ft{Gl>) > €(G™), V* e G u m , VG m g n s (23) 

$(<&) > f jf (G m ), V/ G Gl, f + j, \/G m G n s (24) 

where G^, = Un s G m . The first condition in (|22~l> guarantees for a provider to improve its own 
payoff by performing the merging decision. The other conditions guarantee that none of the 
other members (both users and providers) in the newly formed group decreases their payoffs 
by the merging decision. For every single merging decision, the group structure Vt is updated 
to ^ = (nt,L) where IT = (n\{VG m G II J) U G ] m , where |n+| < |n|. 

Splitting: Given the original group G m , members in this group can collectively split into 
multiple groups G^„ whose set after the splitting is denoted by IT*, if the following conditions 
are satisfied: 

3j G (? m 3Gl G IlJ, ^(Gl) > <%(G m ), G m G U s (25) 

3Gl G nj, W(Gl) > ft(G m ), Vz G G u m (26) 

3(4, G IlJ, 4(aL) > 4> P r {G m ), Mo* G Gl, f ? j (27) 



where G m = U^GL and for all G x , there exist (i, j) G L such that i G Gf", and ? G G*?,. The 



'm ^ n 



first condition in (|25|) guarantees for a provider to improve its own payoff by performing the 
splitting decision. The other conditions guarantee that none of the members in newly formed 
groups decreases their payoffs by the splitting decision. For every single splitting decision, the 
group structure Q is updated to ft* = (n*, L) where 11* = (n\G m )U{VG^, G n*} where |n*| > |II|. 

Figure |4jb) illustrates example group structures after migrating, merging, or splitting decision 
given the group structure in Figure Ufa). For example, after the migration by u 3 , the group struc- 
ture changes to G = {4}, Gi = {{1, 2}, {1, 2, 4}}, G 2 = {{3, 5}, {3}}, and L = {(1, 2), (2, 1), (3, 3), (4, 0), (5, 3); 
After the merging by p 2 , the groups 1 and 2 become one group G 1 = {{1,2,3,5}, {1,2,3,4}} 
with the same associated links. After the splitting by p 2 , the group 1 is splitted into G± = 
{{2}, {1,4}},G 3 = {{1,3}, {2}} with the same associated links. 

Algorithm |2] shows a pseudocode of the proposed group formation algorithm that finds a 
stable group structure. At the beginning (Line 3), the algorithm initializes a group structure fi 
by randomly setting groups and associated links (Lines 4 and 5 in Algorithm [3}. A randomly 
initialized group structure converges to the stable group structure for participants by repeatedly 
selecting distributed decisions (Lines 9, 13, and 16) that improve both users and providers' 
payoffs. During the iterations (Lines 4-18), a history set H is maintained, which stores the groups 
that are formed or evaluated in the past. To compute the payoffs, Algorithm 1 is executed. The 
algorithm stops when none of the participants changes their groups (Line 18). 
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Algorithm 2: findGroupStructure(I?t, O t , Qt) 



Input: B t : a set of bids (from a set of users I t ) 

O t : a set of offers (from a set of providers J t ) 

Q t : the current group structure at time t 
Output: Qf : the final group structure 

1 H 4— //A history set of previously seen groups 

2 I* Randomly initialize a group structure at the beginning */ 

3 if Q t == then Q «— initGroupStructure(I t , Jt) //Algorithm 3 

4 repeat 

5 
6 

7 



/* Gz'yen #ze current group structure Q */ 
foreach user j 6 l f do 

/* i searches a provider f that satisfies (|2IT ). 

If such f is found, and G m > U i ^ H, then i performs a migrating operation. */ 

Qt <— Migrating(i, Q) 

10 foreach provider j e J t do 

n I* j searches a possible group G m > that satisfies (I22l)-(l23l. 

12 If sue?? group zs found, and G m > ^ if, then j performs a merging operation. */ 

13 Q t ^~ Merging(Q,j) 

14 I* j searches a possible partition of its own group G m , which satisfy (I25l)-(l26l>. 

15 If such partition is found, and G*^ £ H, then j performs a splitting operation. */ 

16 Q t <— Splitting(Q,j) 

17 H <- H U G, VG e n of Q t 

is until None of users and providers changes their groups. 
19 return Qf <— Q t 



Algorithm 3: initGroupStructure(/t, J t ) 

Input: I t '. a set of users, J t : a set of offers 
Output: Q°: an initial group structure 
i G*,G? <-<&, for j = l,...,\J t \ 

2 foreach user i e I t do 

3 mf- rand(l, \J t \) 

4 G^ 4- G^ U {*} 

5 L <- L U (i, m) 



6 foreach provider j e J t do 

7 [_ G, <- G? U (Gj = {j}) 

8 Return fi° = {Gi,...,G| Jt |} 



5 Analysis of the Group Formation Algorithm 

This section gives a theoretical analysis of the proposed group formation algorithm in terms 
of the time complexity and stability Subsequently, we discuss that the proposed group auction 
system holds three auction properties described in Section 13.31 
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5.1 Time complexity 

The binary integer programming formulated in Section I4.2.2I is known to be NP-hard that 
the number of different allocations to be evaluated exponentially increases as the numbers of 
users and providers increase. For example, the numbers of users and providers are iV and 
M, respectively There exist T(N, M) possible mappings (i.e., instance allocations) between the 
users and providers where T(n, m) = ^™ =0 (™) • T(n — i,m — l) when T(0, k) = 1 for V/c G N° and 
T(k + , 0) = for Vfc + G N + In addition, if we consider the number of time slots S in a demand 
period, then the number of possible combinations of the mappings increases to T(N, M) s , which 
is factorial 0(N\) in O-notation. 

The proposed group formation by Algorithm [2] is quadratic to the number of participants. The 
algorithm contains a loop (Lines 4-18) that evaluates decisions of participants. For each single 
decision, we need to compute the instance allocation by Algorithm [TJ whose complexity is linear 
O(S-N-M) to participants and time slots. If the loop is executed for k times, then Algorithm 
1 is run for k ■ (N+M) times. Therefor, the complexity of the proposed group formation is 
0(k-(N+M)-S-N-M) ~ 0(k-S-N 2 ) in O-notation when iV > M. 

5.2 Stability 

The stability of the proposed group formation algorithm is guaranteed by the concept of Nash 
equilibrium described in 11291 . We relax the stability conditions by considering a relaxing param- 
eter e > (epsilon) as follows. 

Theorem 1. Given any initial group structure, the proposed group formation algorithm always termi- 
nates, i.e., converges to a final group structure. 

Proof: Let Vt r nr denote the group structure formed after n r decisions made by one or more 
participants during r iterations of Algorithm |2] (Lines 4-18). Starting from any initial group 
structure VLq, the proposed algorithm iteratively transforms the group structure into another 
group structure by taking a sequence of migrating, merging, and/or splitting decisions. The 
sequence of decisions yields the following transformations of the group structure 

QO = Ql _^ Ql _^ y Ql =n 2 __> y Qr = ^r+1 ^T / 2 g) 

1 n\ ni n r n r tit V^W 

where the operator — > indicates the occurrence of one of three decisions. In other words, VL r nr — > 
^J^i implies that during the (r + l)th iteration, n r+1 — n r decisions are made by participants, 
which results in a new group structure f^* starting from a group structure Vl r nr . By inspecting 
the conditions for the decision making defined in (|2TT) - (|26|) and a history set of previously seen 
groups, it can be seen that every single decision leads to a new group structure that has not yet 
visited. Hence, for any two group structures Vt^ and Vt b n where n a ^ n b in the transformations 
in (|28), it is true that Vt a na ^ Vt h nb . 

Given this property and the well known fact that the number of possible group structures 
formed by a finite set of participants (i.e., I and J) is finite and given by the Bell number 

4. N° indicates a set of non-negative integers, and N + is a set of positive integers. 
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II30L the number of transformations is finite. Therefore, the proposed group formation algorithm 
always terminates and converges to one group structure Vl T T = Vl F , a final group structure. □ 

Definition 1 (e-Nash equilibrium). A group structure Vt = (II, L) is e-Nash-stable if for all users i G I, 
<Pt(G m ) > <f>?{G m , U {i}) -e,ie G u m , and for all providers j e J, $(G m ) > tf(G m , U {j}) -e,je G? m , 
for all other groups G m > G II, G m ^ G m >. Nash equilibrium is a special case of e-Nash equilibrium with 

6 = 0. 

In the e-Nash-stable group structure, no users /providers can gain an extra payoff more than 
e by unilaterally moving from its current group to another group. 

Proposition 1. Any final group structure VL F obtained by the proposed group formation algorithm is 
e*-N ash-stable. 

Proof: Assume that the group structure Vl F = (n F , L F ) obtained by the proposed algorithm 
is not Nash-stable (i.e., e = 0). There are two cases to be considered. 

Case 1: There exists a user i in G m and a group G m > G II F such that cj)f(G m / U {i}) > 4>f(G m ). 
Therefore, the user can perform a migrating decision to improve its own payoff. Similarly, there 
exists a provider j in G m and a group G m > G II F such that 4> P j(G m i U {j}) > (j^(G m ). This implies 
that the provider can perform merging and splitting decisions to improve its own payoff under 
the true conditions in (|23|) and (|24)) , and ((261) and <(27j>. This contradicts with the fact that the 
group structure il F obtained by the proposed algorithm is the converged group structure, proved 
in Theorem [T] 

Case 2: Although the provider has an incentive to move from its current group to another 
group, no further transformation by performing a merging (or splitting) decision can be made 
when the condition in (|23|) or (|24l> (or (|26|) or (f27l> ) is false. If we relax the stability conditions by 
considering a relaxing parameter e* > 0, then tt F is e* -Nash-stable where e* = (e* u , e* p ) is defined 
by 



e = max 



Vie/,VG m ,en F 

max 
VjeJ,VG m ,enf 



e* p = max 



max (0, 0«(G" m U {z}) - <%{G m j) }, and 
max (O, #(C m U {j}) - ^{G„ 



n 

As we can easily see, the lower value of e* is preferred in terms of the perfection of the Nash 
stability. 

5.3 Auction Properties 

This section discusses about three auction properties (allocative efficiency, individual rational- 
ity, and budget balance) presented in Section 13.31 and shows that the proposed group auction 
theoretically holds the properties. 

Proposition 2. The instance allocation associated with the group structure obtained by the proposed 
group formation algorithm is allocatively efficient. 
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Proof: Given a group structure and the associated instance allocation, assume that there 
exists a provider who can gain extra utility by merging existing groups or splitting its current 
group. However, the conditions in (|23]> and (|24|) , or ((26)) and ((27)) for the decisions restrict the 
merging or splitting which reduces the others' utilities. Thus, the provider does not perform 
the decision. For users, migrating to the other group does not decrease the other users' utilities 
due to the assumption of the non-increasing price curve. That is, a trading price of instances 
does not increase when the number of users increases. Consequently, no providers gain utility 
by decreasing the others' utilities. □ 

Proposition 3. The instance allocation associated with the group structure obtained by the proposed 
group formation algorithm is individually rational. 

Proof: This proposition is guaranteed by the line 22 in Algorithm [T] and the trading price 
computed from the expression in ((12)) . Any user's valuation Vi does not exceed any provider's 
valuation Vj derived from its price curve and the allocation. In addition, the trading price for 
instances is ranged between the Vi and Vj due to a parameter k G [0, 1]. □ 

Proposition 4. The instance allocation associated with the group structure obtained by the proposed 
group formation algorithm is budget-balanced. 

Proof: This proposition is guaranteed by our design of trading price described in Section 14.2.31 
From Equations in ((131) an d ((14)) , 



J2 Ci = J2 Yl Yl p^ = EEE p*» = H r ^ ( 29 > 

ieh ieit s=t?+ijeJt jeJ t ieh s=tf+i jeJ t 

which implies that the total payments by users is the same as the total profits of providers. □ 

6 Evaluation 

This section numerically evaluates the convergence (in Section I6.1|) and optimality (in Section 
I6.2|) of the proposed group formation algorithm and presents the advantages of the proposed 
real-time group auction system by showing comparison results with different schemes through 
the simulation (in Section |6.3|) . 

6.1 Convergence 

We verify the convergence of the proposed group formation algorithm from two perspectives. 
The first is whether the algorithm always converges over iterations given any parameter setting 
(e.g., the number of users, their demands, valuation, etc.) The second is how the randomly 
given initial group structure (Line 2 in Algorithm [2) impacts the final group structure (Line 18 
in Algorithm |2]). 



Figure [5(a)1 shows how social welfare, i.e., the total utilities defined by Equation ©, improves 
over iterations at given instance allocation in different configurations of bids and offers. In the 
figure, x-axis is the iteration index of the group formation algorithm, and y-axis indicates the 
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TABLE 3: Parameter setting for bids and offers. This is used in Figures 5(a) and [6] 



User's bid 


Provider's offer 


Demand: # of instances 


di e [0, 10] 


Supply: # of instances 


Sj e [10,30] 


Demand Period: Length 


£e [1,6] 


Supply Period: Length 


m,-e[l,6] 


Starting time 


*?e[i,3] 


Starting time 


tjG[l,3] 


Ending time 


if e [tf+4, t\ +e t +6] 


Ending time 


*| = i|+^ 


Valuation 


Vi€[0,V] 


Valuation 


% [i]e[5,io] 




V=10 • ^ • A 




<&[n]e[i,e&[l]-l] 



total utilities of users and providers, whose value is normalized to the value at Iteration 20. The 
result is obtained with 8 users and 2 providers requesting for/providing for one instance type 
under following bids and offers generated based on parameter setting described in Table |3] For 
the user's valuation, we simply set the maximum valuation-per-unit as 10 cents (i.e., $0.10 for 
one instance-per-time-slot), and then we multiply the unit price by the number of instances and 
length that a user requests. For example, for a user who requests instances of di = 5 for £i = 3, 
the value of his valuation is uniformly generated between and 10 • 5 • 3 = 150 cents (=$1.50). 
For the provider's valuation, price curves are randomly generated with g^[l] e [5, 10] followed 
by qj[l] = ■ ■ ■ = qj[n — 1] > qj[n] = ■ ■ ■ = qj[sj] where n 6 [2, Sj]. The line plots in the Figure 5(a) 
are the results of 10 randomly generated configurations of bids and offers. The initial group 
structure is set to II = (C7 = {1,...,8}, G x = {0,{1}}, C7 2 = {0,{2}}) and L = {(*, 0)|* = 1,...,8} 
for all cases. The values are normalized to the values at Iteration 20. 

In Figure 5(a)[ we observed three trends in the value improvement. For example, the value 
increases more at early iterations (Trend 1), the value increases more at later iterations (Trend 
2), and the value gradually increases over some iterations (Trend 3). We observe that for all of 
10 different configurations, Algorithm [2] converges to some values after several iterations. The 
optimality will be discussed in the next subsection. 

Figure |5(b)| shows how the initial group structure impacts the final group structure. For this 
measurement, we generate one configuration as described in Table HI We run Algorithm |2] ten 
times with 10 different randomly generated initial group structures. The solid-line plots indicate 
the social welfare improvement over iterations. A dashed line indicates the sum of the values e* 
(i.e., a relaxing parameter) of participants, which corresponds to one case denoted by a circle- 
pointed line. It is seen that, during the process of group formation, the sum of e* gradually 
decreases and eventually reaches to 0. This implies that the obtained group structure is Nash 
stable (i.e., e*-Nash stable with e*=0) in this case. We verify that the algorithm finds one group 
structure whose social welfare is 118 regardless of initial group structures. 



6. 1. 1 An Example Allocation after Convergence 



Figure 5(c) shows the group structure and instance allocation obtained at Iteration 20 with one 
initial group structure II = (G = {1,2,3,4,5,6,7,8}, G x = {0,{1}}, G 2 = {0,{2}}) and L = 
{(i,0)\i = 1, ... ,8}, denoted by a circle-pointed line in Figure |5(b)| The final group structure 
becomes II = (C7 = {4}, G x = {{1,2,3,5,6, 7,8}, {1,2}}), and L = {(1,2), (2,2), (3, 1), (4,0), 
(5, 1), (6, 1), (7, 2), (8, 1)}. There are some important observations in this result as follows: 
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TABLE 4: An example bids /offers configuration for 8 users and 2 providers, generated under 
parameter setting in Table I. This is used in Figures 5(b) and 5(c) 



Bids 


Offers 


Demand 


Ul 


U2 


«3 


«4 


115 


Me 


m 


«8 


Supply 


Pi 


P2 


# of instances 


2 


2 


2 


5 


5 


5 


10 


10 


# of instances 


20 


20 


Period: Length 

Starting time 
Ending time 


4 
1 
6 


5 
1 
6 
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Fig. 5: Impact of bids/offers configurations and initial group structures on the social welfare 
improvement by the proposed group formation algorithm. 



• In time slot 1, Users 3 and 8 are assigned to Provider 1 because Provider 1 offers lower 
price ($.50) than Provider 2 ($.60). Users 1 and 2 are not assigned in time slot 1 because 
they can get more discount by being allocated after time slot 2 with other users. Users 1 
and 2 cannot obtain the discount in time slot 1 with Users 3 and 8 because the total number 
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of demands is 14, which does not affect price curves of providers. 

• User 4 cannot be allocated by any providers. There are no sufficient supplies (e.g., 17 
instances for Provider 1 and 19 instances for Provider 2) between time slots 2 and 5. That 
is, User 4 loses the auction due to relatively lower valuation ($0.5 per-unit) than the others. 

• In time slots between 2 and 5, Provider 2 accepts Users 1, 2, 6, and 7 whose valuations are 
relatively higher than other users. The valuation of Provider 2 becomes lower than that of 
Provider 1 when the number of total supplies exceeds 15, which results in the increase of 
social welfare. User 3 with the highest valuation among all users remains to be assigned to 
Provider 1 because of the migration cost. 

• User 8 is assigned in time slots between 1 and 6 (but not between 2 and 7). Given higher 
valuation of User 3 ($1.5 per-unit) than that of User 6, the sum of utilities of Users 3 and 8 
at time slot 1 is larger than that of Users 6 and 8 at time slot 7. 

• Instances for User 6 are migrated from Provider 2 to 1 in time slot 7 due to the lower 
valuation of Provider 1. 

6.2 Optimality 

We also verify that the proposed instance allocation, i.e., the outcome of Algorithm 1, is nearly 
optimal compared with an enumeration method, in which all possible allocation combinations 
are evaluated. In addition, we compare the allocation in a different scheme called IA-FCFS, which 
stands for an Individual Auction by the First-Come-First-Serve allocation. In this scheme, users 
individually join an auction in a first-come-first-serve manner, and their demands are allocated 
to providers in the order of valuation from the lowest among providers with sufficient supplies. 
We call GA-BCT (i.e., Group Auction is executed at the Bidding Closing Time) for our proposed 
instance allocation given by Algorithm 1. 

Figure [6] shows the statistics (e.g., maximum, minimum, and quarter percentiles) of the social 
welfare (i.e., the total utilities of participants) over 100 randomly generated configurations of 
bids and offers based on the parameter setting described in Table |3l The initial group structure 
is randomly generated. The maximum number of iterations is set to 20. The number in the box 
indicates the sum of the differences of the values from the ones obtained by the enumeration. 

In Figure [6f a )/ the statistics for GA-BCT are better than those for IA-FCFS. The main reason 
is that instances are efficiently allocated to users so that they get price discounts, which leads 
to the increasing social welfare. It also shows that the maximum value for GA-BCT is the same 
as that from the enumeration although the percentile values are lower because the proposed 
allocation cannot find the optimal solution in some configurations. We also investigate the impact 
of the numbers of users and providers on the results in the Figures [6flb)-(d). As the number of 
participants increases, the difference of values in GA-BCT and Brute-force increases. GA-BCT 
might not find the optimal value; however, the statistics for GA-BCT are still nearly the same 
as the optimal and definitely higher than those for IA-FCFS. 
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Fig. 6: The statistics of the social welfare over 100 randomly generated configurations. Y-axis 
indicates the social welfare given allocation, and the number in the box is the sum of the 
difference of the value from the one obtained by Brute-force. 



6.3 Simulation Results 

This section presents a real-time simulation of the proposed group auction system and discusses 
its advantages in terms of the number of auction winners, resource utilization, and total profit 
of providers by showing comparison results with different schemes. 

6. 3. 1 Parameter setting for the simulation 

The simulation code is written in Matlab and run on a local machine (Intel Xeon 3.6GHz, 
4G memory). The input data is generated based on parameter settings described in Table |5j 
The obtained results vary based on the generated input data. Because we do not have certain 
statistics (e.g., volume, period, requirement, etc) about user requests to the real cloud markets 
(e.g., SpotCloud, AmazonEC2, etc), we generate the input data with a uniform distribution. 

We run the simulation for SimT=72 time slots period (e.g., 72 hours). During the period, we 
fix 2 providers each of whom supplies 50 instances for each of 3 different types (i.e., K=3). We 
assume that n b T , the number of new arrival users within time slot r, is randomly selected between 
and 3. Each user's bid is randomly generated. Similar to the parameter setting described in 
the previous section, we set the maximum valuation-per-unit for instance type k as 10k cents 
and multiply the unit price by the number of instances and length that a user requests. For 
example, for a user who requests instances of di = (8, 5, 3) for l t = 3, the value of his valuation 
is uniformly generated between and 3 • (10 • 8 + 20 • 5 + 30 • 3) = 810 cents (=$8.10). For the 
provider's valuation, price curves are randomly generated with g^[l] G [5k, 10k] followed by 
#[!] = •• 



qj[n — 1] > q!j[n] 



q'jls'j] where n E [2,sf]. For the provider's valuation, we 



set price curves as shown in Figure For example, Provider l's price curve for type k — 1 is 
q\\l] = $0.05 and ^[31] = $0.03 while Provider 2's price curve is ^[1] = $0.06 and ^[16] = $0.04. 

6.3.2 Comparison 

In this section, we compare the proposed group auction scheme, called GA-BCT-GF (i.e., Group 
Auction is executed at the Bidding Closing Time in each of groups determined by Group 
Formation algorithm), with different schemes, i.e., IA-FCFS and GA-BCT. Differences among the 
schemes are summarized in Table [61 The main differences are usages of Algorithms [1] and |2] In 
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TABLE 5: 


Parameter Setting 


for the Simulation 




Simulation time period 


SimT = 72 


# of instance types 


K = 3 


# of arrival users within time slot r 


K e [o, 3] 


# of providers 


n° = 2 


User's bid bi 


Provider's offer Oj 


Demand: # of instances of type k 

Demand Period: Length 

Starting time 
Ending time 

Valuation 


df e [o, 10] 

^iG [1,6] 

if e [r+1, t+3] 

t\ G [tl+ii, tf+ti+6] 

Vi ^Uniform(0, V) 

V=£iE k& K^k-d^ 


Supply: # of instances of type k 

Supply Period: Length 

Starting time 
Ending time 

Valuation 


s 1 = 20 
Wj — SimT 

t) = SimT 

Qj = [<Lj k ] 
(Fig.E) 
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Fig. 7: Example price curves for Provider 1 and 2 for instance type of k=l, 2, and 3. 



IA-FCFS, both algorithms are not used; instead, users individually join an auction in a first-come- 
first-serve manner, and their demands are allocated to providers in the order of valuation from 
the lowest among providers with sufficient supplies. In GA-BCT, whenever new participants 
arrive to the system, the instance allocation is computed by Algorithm [T] for all participants and 
executed at the bidding closing time. In GA-BCT-GF, Algorithm [2] is used to construct a group 
formation. The instance allocation is computed by Algorithm [T] and executed at the bidding 
closing time for each of the groups. 

Figure [8] shows the number of auction winners and losers during the simulation period in 
different schemes. Table [7] summarizes the comparison results in terms of the total number 
of winners, resource utilization, profit of providers, and average payment of users. From the 
number of winners, the request acceptance rate of users, which is the number of winners divided 
by the total number of users, will be obtained. The resource utilization is given by the total 
allocated (i.e., provided) instances divided by the total supplies of providers. The last column 
in the table indicates the improvement of the results by GA-BCT-GF compared to IA-FCFS. 

The impact of the group bidding becomes stronger with a dynamic bid closing time. In GA- 
BCT-GF, a central controller retains more bids before submitting a group bid. That is, the total 
number of requested instances becomes larger than that of IA-FCFS. This results in providers to 
lower their offering prices, so more users have a chance to win the auction. For example, during 
a time period between t=7 and 12 (indicated by a dotted box), 10 users in total join auctions. 
Among the 10 users, 9 users win the auction in GA-BCT-GF while only 4 users win in IA-FCFS. 
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TABLE 6: Description of different schemes 





Description 


Dynamic 

Allocation 

(Algorithm 1) 


Group 

Formation 

(Algorithm 2) 


Cooperation 


IA- 
FCFS 


Users individually join an auction in a first- 
come-first-serve manner, and their demands are 
allocated to providers in the order of valuation 
from the lowest among providers with sufficient 
supplies. 


No 


No 


No partici- 
pants coop- 
erate. 


GA- 
BCT 


All users and providers join a group auction 
where the instance allocation is computed by 
Algorithm 1 and executed at the bidding closing 
time. 


Yes 


No 


All partici- 
pants coop- 
erate. 


GA- 
BCT-GF 


All users and providers are divided into multiple 
groups by Algorithm 2. The members in each 
of the groups join a group auction where the 
instance allocation is computed by Algorithm 1 
and executed at the bidding closing time. 


Yes 


Yes 


Participants 
cooperate 
in their own 
groups. 



Similar results can be observed during a time period between £=31 and 39 (6 users win in GA- 
BCT-GF while 3 users win in IA-FCFS). As shown in Table the total number of winners of 
GA-BCT-GF (60 (81.1%)) is larger than that of IA-FCFS (53 (71.6%)). GA-BCT-GF achieves 13% 
of the improvement in the request acceptance rate. 

The proposed group formation also impacts on the total number of winners. It can be observed 
that users in GA-BCT-GF have more chance to win an auction before their deadline than those 
in GA-BCT Since the GA-BCT considers one group of all cooperating participants, once the 
allocation is determined, it is executed at the bidding closing time of the group. For example, 
at time £=9, 2 users lose the auction in GA-BCT (indicated by an arrow) while, in GA-BCT-GF, 
the group including the users did not execute the allocation immediately because the bidding 
closing time has not met yet, but at £=12. Similar results can be observed at time £=17, 23, 30, 
and 40. The total number of winners of GA-BCT-GF (60) is slightly larger than that of GA-BCT 
(58) as shown in Table [71 

In terms of the total profit, considering a group auction, Provider 2's profit increases from 
$145.8 (IA-FCFS) to $208.4 (GA-BCT) and $212.1 (GA-BCT-GF) while Provider l's profit decreases 
from $236.3 (IA-FCFS) to $186.2 (GA-BCT) and $191.7 (GA-BCT-GF). The reason is that when the 
number of requested instances is large (e.g., between 15 and 30 in Figure [7)), Provider 2 offers 
cheaper prices than that of Provider 1. Consequently, the total number of provided instances by 
Provider 1 decreases, and hence, the profit slightly decreases. However, if more users participates 
the auction, then Provider l's profit increases again due to Provider 2's supply limitation. 

During the simulation, 8640 instances (= 2 providers x (20 instances x 3 types) x 72 SimTime) are 
supplied by providers, and 6090 instances (D = (2224, 1831, 2035)) for IA-FCFS, 6405 instances 
= 2655, 2102, 2398)) for GA-BCT, and 7668 instances (D = 2942, 2195, 2531)) for GA-BCT-GF 
are allocated, respectively. Due to the optimal instance allocation computation in GA-BCT and 
GA-BCT-GF, the resource utilization improves from 70.5% (=6090/8640) to 82.8% (=7155/8640) 
and 88.7% (=7668/8640), which shows 26% of the improvement. It follows that the total profits 
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TABLE 7: Summary of simulation results. 







Scheme 


Improvement 




IA-FCFS 


GA-BCT 


GA-BCT-GF 


#Winners (#Losers) 


53(21) 


58(16) 


60(14) 


13% | 


Total # of allocated 
instances (D\D 2 ,D 3 ) 


6090 = (2224, 
1831, 2035) 


7155 = (2655, 
2102, 2398) 


7688 = (2942, 
2195, 2531) 


- 


Resource utilization 


70.5% 


82.8% 


88.7% 


26% t 


Total 
profit 


Provider 1 

Provider 2 

[Sum] 


$236.3 

$145.8 

[$382.1] 


$186.2 

$208.4 

[$394.6] 


$191.7 

$212.1 

[$403.8] 


6% | 


Avg. payment per user 


$7.21 


$6.84 


$6.73 


7%| 



of all providers increases from $382.1 for IA-FCFS to $403.8 for GA-BCT-GF (i.e., 6% of the 
improvement), which also gives the 7% of decrements in the average payment (i.e., the average 
cost) for users from $7.21 for IA-FCFS to $6.84 for GA-BCT-GF. 

Finally, we evaluate the system in the average case analysis^ Table |8] shows the statistics 
(e.g., average and standard deviation) of the results over 100 simulation runs based on the 

5. In our simulation, different input data were generated in different simulation runs. So, it is hard to show the confidence 
interval of the results. If we run the simulation with the same set of bids and offers, then our system results in the almost same 
instance allocation. It means that the confidence interval is approximately 100% but there is no meaning to us. This is one of 
the reasons to show the average case analysis rather than the confidence interval. 
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same parameter setting (Table 3). The standard deviation is slightly high because the total 
number of users arrived during the simulation time period (SimT = 72) is different in different 
simulation runs. However, GA-BCT-GF still outperforms the other schemes in this average case 
analysis. GA-BCT and GA-BCT-GF accept more users (i.e., more winners) than IA-FCFS, which 
leads to increase the profit of providers. Provider 2 gains more profit than that of Provider 1 
when considering the group discount. GA-BCT-GF produces more efficient instance allocation 
by considering a group formation than that of GA-BCT, which leads to improve the resource 
efficiency in terms of its utilization. 

TABLE 8: Statistics (Avg ± Stddev) of the results over 100 simulation runs. 







Scheme 




IA-FCFS 


GA-BCT 


GA-BCT-GF 


Avg of #Winners 


53.57 ± 4.24 


59.85 ± 7.78 


62.88 ± 4.95 


Avg of Resource utilization 


69.26% ± 2.83% 


81.01% ± 2.83% 


85.24% ± 4.24% 


Avg of 

Total 
profit 


Provider 1 

Provider 2 

[Sum] 


$242.4 ± $32.1 

$175.1 ± $42.3 

[$394.1 ± $20.2] 


$201.8 ± $28.8 

$223.4 ± $47.6 

[$429.3 ± $71.3] 


$202.5 ± $22.1 

$238.7 ± $52.1 

[$442.4 ± $67.5] 



In summary, the proposed real-time group auction system with cooperation outperforms two 
different schemes, mimicking existing cloud hosting services, in terms of the resource efficiency 
(e.g., 13% higher request acceptance rate for users, obtained from the number of winners, and 
26% higher resource utilization for providers) and monetary benefits (e.g., 7% lower average 
payments for users and 6% higher total profits for providers) with the considered simulation 
setting. We have shown these advantages in the average case analysis. 



7 Conclusion 

This paper has proposed a real-time group auction system in the cloud instance market, and 
the simulation studies have verified its applicability and effectiveness in terms of resource 
efficiency and monetary benefits to auction participants. We have shown that the proposed 
system outperforms two different schemes, mimicking existing cloud hosting services, in terms of 
resource efficiency and monetary benefits. The proposed group formation and instance allocation 
algorithms have been analyzed in their complexity, stability, and optimality The obtained results 
have shown that the algorithms with quadratic time complexity find nearly optimal group 
structures regardless of configurations and initial conditions. 

As our future work, we have left a few issues that have not solved yet and interesting 
research directions as follows. First, when to execute the proposed algorithms and when to close 
the auction are important problems in real-time auction because the computation of instance 
allocation and group formation have time overhead. In the current system, the bid closing time 
may not be the best. Finding the best bid closing time is challenging. Second, we will improve the 
scalability of our algorithms to accommodate more participants in a reasonable time. In this paper, 
we have mainly focused on the design of the system model and algorithms, and we have shown 
the theoretical justification instead of evaluating a large number of participants. Third, we will 
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investigate various bidding strategies of participants and also different price determination schemes to 
know how they affect the monetary benefits to the participants. Those are pre-determined in the 
current system. Finally, we will also consider our approach in various and complex situations. 
For example, when a user requests multiple applications that have dependency, it might be 
interesting to investigate the best resource provisioning, i.e., where (or which machines) to locate 
which application, in terms of the performance such as response time and throughput. It might 
be also interesting to consider the case that two users request the same application operated by 
the same provider, and the two users share the resources for the application. 
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